@jennings love the initiative!

Just a couple of questions:

• how do you avoid the issue of agent's "natural tendency" to use git instead of jj?
• how do you avoid the issue of having multiple agents pushing (jj git push) to the same repo causing lock contention?

• how do you avoid the issue of agent's "natural tendency" to use git instead of jj?

To be honest, I haven't thought that much about it yet. I don't really ask the agent to commit things very often. I know this is a common workflow, though, and people have had success putting instructions in their AGENTS.md to use jj instead of git.

Perhaps it should be a config setting prefer_jujutsu or something, instead of automatically preferring jj workspaces over git worktrees in a colocated repo.

• how do you avoid the issue of having multiple agents pushing (jj git push) to the same repo causing lock contention?

If you really mean pushing, then I think it has the exact same problems as pushing from a git worktree. Remotes can't tell if git or jj are pushing to them (other than the fact that the commits they're receiving usually have an extra change-id header). In fact, pushing and fetching are actually handled by executing git commands.

However, I think you may mean just "updating the (local) repo with changes", similar to git commit. jj's data structures support concurrent access. However, the underlying git repo doesn't and so jj acquires a lock on it.

• how do you avoid the issue of agent's "natural tendency" to use git instead of jj?

To be honest, I haven't thought that much about it yet. I don't really ask the agent to commit things very often. I know this is a common workflow, though, and people have had success putting instructions in their AGENTS.md to use jj instead of git.

Perhaps it should be a config setting prefer_jujutsu or something, instead of automatically preferring jj workspaces over git worktrees in a colocated repo.

nice! the flag you mention seems like a must, we can't have a mix of worktrees and workspaces in the same repo, right? this is explicitly forbidden in the docs for jj

• how do you avoid the issue of having multiple agents pushing (jj git push) to the same repo causing lock contention?

If you really mean pushing, then I think it has the exact same problems as pushing from a git worktree. Remotes can't tell if git or jj are pushing to them (other than the fact that the commits they're receiving usually have an extra change-id header). In fact, pushing and fetching are actually handled by executing git commands.

However, I think you may mean just "updating the (local) repo with changes", similar to git commit. jj's data structures support concurrent access. However, the underlying git repo doesn't and so jj acquires a lock on it.

sorry didn't explain myself very well, to my understanding if you're using workspaces in a co-located repo, while having multiple agents making changes then jj is forced to sync w the underlying git repo on every change, thus creating potential lock contention in the git store
I might be missing something here, but it seems like this is what the docs are referring to in this section

does that make more sense?

we can't have a mix of worktrees and workspaces in the same repo, right? this is explicitly forbidden in the docs for jj

You can use worktrees and workspaces in the same repo. I am doing it today with Agent Deck and other similar tools.

What I think you're referring to is that only the default workspace (the first one you get when you jj git clone) can be colocated with git. Any additional workspaces are not colocated, so git commands can't be used in them. It still stores everything in the git repo, it just isn't a git worktree.

This isn't a fundamental limitation, I expect this feature to be added sometime. Several people have started work to make workspaces also contain git worktrees, but it seems it's more work than you'd expect.

while having multiple agents making changes then jj is forced to sync w the underlying git repo on every change, thus creating potential lock contention in the git store

I think you might be worried that every change to any file might trigger a snapshot (amend the working copy commit).

There is no daemon watching files on disk get changed, by default. Instead, each time you run any jj command, the first thing jj does is the equivalent of git commit --amend -A. So, the sync only happens when the agent or human chooses to run a jj command. This is the same amount of contention that git worktrees have because they're all operating on the same object and ref storage.

There is an optional integration with watchman to automatically snapshot when files are edited, but it's not on by default.

I might be missing something here, but it seems like this is what the docs are referring to in this section

I think this is the same problem you'd have using git over NFS, no? The jj storage should be safe over NFS, the warning is referring to git not being fully safe to use concurrently.

ty @jennings for patiently answering all my n00b questions around jj :)

It's all good, I just want more people to learn about jj 🙂

If you're interested, come join our Discord. We're a friendly bunch and newcomer questions are welcome.

I intend to complete and publish this, but I want to refactor the implementation first. I don't like that GitBackend and JJBackend are currently just thin proxies around package-level functions, I think the functions should be folded into the methods.

I've done that work, but just haven't found the time to really vet it and make sure it's not doing anything crazy.

In the meantime, feel free to close this draft PR if it's a nuisance.